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Generisches Alignment-Verf ahren in einer Multi-Manager-Umge- 
bung 

Die Erfindung betrifft ein Verfahren und ein Kommunikations- 
system zum Datenabgleich durch ein zumindest zwei Manage- 
mentebenen aufweisendes Managementnetz gemafi den oberbegriff- 
lichen Merkmalen des Anspruchs 1, wobei insbesondere fttr z.B. 
einen generischen Alarmdatenabgleich zwischen einem Agent ei- 
ner Managementebene und einem Manager einer nachsthoheren Ma- 
nagementebene die Alarmdaten aktiver Alarme ubertragen wer- 
den. 

Die Prinzipien eines Managementnetzes, die auch als TMN-Prin- 
zipien (TMN: Telecommunications Management Network) bezeich- 
net werden, definieren mehrere Managementebenen ftir das Mana- 
gement eines Kommunikationssystems - beispielsweise eines Mo- 
bil-Kommunikationssystems wobei jede Ebene eine doppelte 
Funktion hat. Im managenden System hat jede Ebene aufler der 
untersten eine Manager-Funktion fur die darunterliegende 
Ebene. Im gemanagten System hat jede Ebene aufier der obersten 
-ei n e A gent-eir-FuirkLion ftir— dre~n^ctrs-trlT Ohere E bene. 

Das Fehlermanagement ("Fault Management") ist z.B. ein wich- 
tiger Teil des TMN-Managements . In der Regel spielt in diesem 
Fall der Agent die aktive Rolle, indem er Fehler-Ereignisse 
der eigenen Managementebene rechtzeitig und genau erkennt und 
an den Manager der nachsthoheren Ebene als Ereignisberichte 
bzw. sogenannte "event reports" (z.B. alarm reports) uber- 
tragt. Die Obertragung von Ereignisdaten vom Agent zum Mana- 
ger ist unkritisch, solange der Kommunikationsmechanismus 
zwischen diesen Systemen nicht gestort ist. Wenn die Verbin- 
dung zwischen den beiden Managementebenen, also zwischen 
Agent und Manager, fur eine bestimmte Zeit nicht mehr gewahr- 
leistet ist, muft der Agent die wahrend dieses Intervalls auf- 
getretenen Ereignisse zwischenspeichern, urn sicherzustellen, 
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dafi nach dem Wiederherstellen der Kommunikationsmoglichkeit 
dem Manager zum einen moglichst schnell eine Ubersicht des 
aktuellen Netzzustandes - z.B. fur aktive Alarme in Form ei- 
ner Liste - zur VerfUgung gestellt wird, und der Manager zum 
anderen eine moglichst liickenlose Geschichte der Ereignisse 
("event history") z.B. der aktiven als- auch der beendeten 
Alarme („cleared alarms") aufbauen kann. 

Zu diesem Zweck wird ein Datenabgleich (data realignment) 
zwxschen Agent und Manager bei jedem neuen Verbindungsaufbau 
nach einem Verbindungsabbruch oder nach einer Initialisierung 
des Agenten oder des Managers ausgefuhrt. Alle Alarmdaten ak- 
tiver Alarme, zu denen Fehler im Agent noch nicht behoben 
sind - erkennbar daran, daB sie nicht als ^cleared alarms" 
gekennzeichnet sind -, sind daher schnellstmoglich und voll- 
standxg der nachsthSheren Managementebene zur VerfUgung zu 
stellen. 




20 
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30 



in der DE 197 52 614 sind ein derartiges Verfahren und Kommu- 
mkatxonssystem zur Behandlung von Alarmen angegeben, die 
eine Basisf unktionalitat ftir den Manager zur Anforderung al- 
ler Alarme vom Agent beschrieben. Dabei sendet der Agent die 
WlVSn Afarme als Sequenz standardisierter M-EVENT-REPORTS 



die in eine vom Manager zu Anfang initiierte M- AC T I ON- Re que s t 
Anforderung und in eine vom Agent zum Ende initiierte M- 
ACTION-Response Antwort eingebettet ist. Dieses sind generi- 
sche CMISE-standardisierte (Common Management Information 
Servxce Element) P.rozeduren, die gemaA ITU-T X.710 definiert 
smd (ITU-T : international Telecommunication Union - Telecom- 
munication sector). Die ITU-T X.733 definiert den Inhalt ei- 
ner standardisierten Alarmubertragung (alarm report), die ge- 
mafi den M-EVENT-REPORT Services durchgefuhrt wird. Alle in 
Rahmen dieser M-ACTION definierten M-EVENT-REPORTS sind zu 
der jeweiligen Anforderung durch Verwendung von Korrelati- 
onsxnformationen eindeutig korreliert. Dies erlaubt dem Mana- 
ger, diese M-EVENT-REPORTS einer bestimmten Anforderung zuzu- 
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ordnen und dariiber hinaus von anderen, „regularen x> M-EVENT- 
REPORTS zu unterscheiden. 





Bei der DE 198 01 785 wird davon ausgegangen, daft fur einen 
Alarmdatenabgleich zwischen einem Agent einer Managementebene 
5 und zumindest einem Manager einer nachsthoheren Management- 
ebene die Alarmdaten aktiver Alarme iibertragen werden. Dar- 
iiber hinaus werden von dem Manager eine Oder mehrere Anforde- 
rungsnachrichten zum Obermitteln der Alarmdaten an den Agent 
gesendet, sowie Korrelationsinf ormationen fur eine Zuordnung 
10 der jeweiligen Anforderung zu den vom Agent nachfolgend ge- 
sendeten Nachrichten mit den Alarmdaten empfangen. 

Dadurch, dafl der Alarmdatenabgleich dort von dem Manager ab- 
hangig von zumindest einem zum Agent gesendeten Parameter ge- 
steuert wird, ist der Alarmdatenabgleich fur den Manager ge- 
15 genuber der Basisf unktionalitat parametrisierbar . D.h. nicht 
mehr alle aktiven Alarme miissen zwangslaufig vom Agent gesen- 
det werden, sondern nur die durch den ubermittelten Parameter 
naher definierten. Damit ergibt sich fur den Manager eine 
Auswahlfunktion fur eine Teilmenge aus alien Alarmen. Dabei 
20 werden standardisierte Nachrichten verwendet. 

Mit dieser Vorgehensweise kann der Manager die im Hinblick 
auf die Funktionalitat besonders kritischen und damit fur ihn 
wichtigen Alarme gezielt abrufen, und dabei die Schnittstelle 
zum Agent durch den nur auf bestimmte Alarme eingeschrankten 
25 InformationsfluB gegenuber dem herkommlichen Verfahren der 
automatischen Meldung aller Alarme wesentlich entlasten. 



In einer Multi-Manager-Umgebung muii der Agent allgemein in 
der Lage sein, Aufgaben von mehreren Managers zu bewaltigen, 
dies auch zur gleichen Zeit. Auf der anderen Seite kann ein 
30 Manager seine Funktion nur dann optimal erfiillen, wenn alle 

relevanten Ereignisse („Event reports") aus den untergeordne- 
ten Agents moglichst schnell empfangen werden, Unter Nor- 
malbedingungen, d.h. wenn die Kommunikation zwischen Agent 
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und Manager (s) funktioniert, geschieht dies uber einen Event 
Reporting- bzw. Ereignisberichts-Mechanismus . Hierbei gene- 
riert der Agent nach Erkennung eines Ereignisses eine ent- 
sprechende Nachricht. Neben den bereits genannten Alarm-Nach 
nchten sind dies z.B. Nachrichten bzw. Notif ikationen zu ei 
ner Zustandsanderung (state change), Objekterzeugung, -16- 
schung (Object creation / Object deletion) oder Attributwert- 
anderungen (Attribute value change Notification) . Diese wer- 
den an eventuell im Agenten vorhandene Ereignisweiterlei- 
tungs-Diskriminatoren (Event Forwarding Diskriminatoren) ge- 
sendet, sogenannte EFDs . 

Die Aufgabe eines EFD besteht darin, nur diejenigen Ereignis- 
berachte zum Manager zu leiten bzw. routen, welche bestimmten 
FUterkriterien genugen. Der Manager ist in der Lage solche 
EFDs im Agent einzurichten oder zu loschen und die Filterkri- 
terien festzulegen. Dadurch kann jeder Manager zu jeder Zeit 
den Informations flufi nach seinen individuellen Anf orderungen 
steuern. 

In einer obj ekt-orientierten Umgebung, wie z.B. zwischen Ma- 

Uager Und Agent in einem Mobilfunk-Netz, wird jede Agent- 

Funktx-o-n-a-rjrtat von emem besTi mmten Objekt als Instanz einer ' 
Ob^ektklasse bereitgestellt . Das Objekt entsteht als Ergebnis 
der Modellierungs-TStigkeit (Definition eines Information Mo 
del) und ist sowohl dem Manager als auch dem aus f uhr enden 
25 Agent bekannt. 

Wie beschrieben, gibt es verschiedene Situationen, in denen 
exn genereller Datenabgleich - sogenannter Alignment - hin- 
sxchtlxch insbesondere Alarmen, Zustanden, Konf igurationsan- 
derungen zwischen Manager (n) und Agent (en) n6tig ist, der 
uber den normalen Ereignisberichts-Mechanismus hinausgeht, 
z.B. nach einem Verbindungsabbruch oder nach einer Initiali- 
sing des Agents oder Managers. Dieser Alignment wird zu- 
mexst auf Manager-Anf orderung (manager request) gestartet 
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Insbesondere fur den Einsatz bei einem Mobilfunksystem der 
dritten Generation, wie UMTS (Universal Mobile Telecommunica 
tion System) soil ein optimales und vorzugsweise standardi- 
sierungsf ahiges Alignment-Verf ahren zwischen Manager (n) und 
Agent (en) moglichst viele der folgenden Kriterien erfullen: 

1. Das Verfahren soil moglichst nur standardisierte Dienste 
Protokolle verwenden und von generischer Natur sein, um 
spezifische Manager- bzw. Agent-Implementierungen zu ver- 
raeiden . 

2. Die Alignment-Information soil - zumindest ftir die soge- 
nannten "mandatory" Parameter - den gleichen Inhalt wie 
die originale Notification enthalten, was vor allem fur 
sogenannte dynamische Informationen, wie Alarme oder Zu- 
stande wichtig ist. 

3. Der Manager soli bei vom Manager zu steuernden Datenab- 
gleichen den Alignment-Start bestimmen und das Alignment- 
Ende eindeutig erkennen konnen. 

4. Der Manager soil zwischen einer "on-line" (normalen) Noti- 
fjreafeion— und— e-irn^i^No-t-irf-^ - di e 

als Folge einer vorher gestarteten Alignment-Prozedur emp- 
fangen wird. 

5. Die durch die Alignment-Prozedur vom Agent gesendeten No- 
tificationen verwenden die gleichen EFDs wie die "norma- 
len" Notif icationen. 

6. Fur die durch die Alignment-Prozedur vom Agent gesendeten 
Notif icationen gelten die gleichen Log-Einstellungen wie 
fiir die "normalen" Notif icationen. 

7. Der Manager kann ein vollstandiges oder nur ein Teil- 
Alignment-Verf ahren anfordern, z.B. abhangig von bestimm- 
ten Parameterwerten. 
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8. In einer Multi-Manager-Umgebung soli jeder Manager 

diejenigen Notif icationen empfangen, die als Folge einer 
von ihm selbst getriggerten Alignment-Prozedur gesendet 
werden, und zwar auch dann, wenn parallel-lauf ende Align- 
ments von mehreren Managers ausgeftihrt werden. 



9 



Der Manager kann auch dann zwischen Notif icationen unter- 
schexden, wenn mehrere eigene Alignment-Prozeduren zur 
glexchen Zeit laufen, z.B. fur unterschiedliche Daten oder 
Netzregionen. 



Bislang gibt es zwei grundsatzliche Arten von Datenabgleich- 
bzw. Alignment-Verfahren: 

a) Der Manager sendet an den Agent eine Anforderung (M-ACTION 
Request bzw. -Anforderung gemaJS ITU-T Standard X 710) 
welche die Alignment-Parameter und eine eindeutige Nummer 
enthalt. Der Agent sendet zuerst eine sogenannte "Start 
alignment-Notification - fur die Korrelation aller durch 
das Alignment-Verfahren gesendeten Notif icationen mit dem 
Manager-Request - und anschlieAend die Alignment-Notif ica- 
txonen an alle EFD-Instanzen . Das Ende der Alignment-Pro- 

ACTION-Response bzw. -Antwort oder durch eine gesonderte 

End alignment-Notification mitgeteilt (CMISE: Common Ma 
nagement Information Service Element) . 

Dieses bereits in Mobilf unk-Systemen verwendete Verfahren 
ist nedoch nachteilhaft, da nicht standardisierte Notifi- 
cations ("Start alignment" / "End alignment") eingefuhrt 
werden. In einer Multi-Manager-Umgebung werden zudem in 
nachteilhafter Weise die durch einen bestimmten Alignment- 
Vorgang gesendeten Notif icationen auch von alien anderen 
Managers empfangen, was unnatige bzw. mehrfach empfangene 
Notif icationen zur Folge hat. Somit werden die vorstehen- 
den Kriterien 1 und 8 nicht erfullt. 




GR 99 P 26 



7 



b) Der Manager sendet eine Anforderung, eine CMISE-standardi- 
sierte M-ACTION-Request, welche die Alignment-Parameter 
enthalt , darunter auch die Filterkriterien fur diese 
Alignment-Prozedur . Der Agent muii dabei zuerst die den 
5 Kriterien entsprechenden Notif icationen bestimmen. Danach 

bildet der Agent eine M-ACTION-Response mit alien diesen 
Notif icationen und sendet diese an den Request-Urheber 
bzw. Manager. 



Dieses Verfahren ist ebenfalls nachteilhaf t, da es eine 
10 spezifische Implementierung bedeutet, weil der Agent zu- 

erst alle potentiellen Notif icationen gemafl den in der M- 
ACTION-Request enthaltenen Filterkriterien uberprufen mufi . 
Dies fuhrt zu einem schlechteren Zeitverhalten der Align- 
ment-Prozedur. Zudem benutzen die Alignment-Notif icationen 
15 nicht die gleichen Filter bezuglich dem Ereignisbericht 

bzw. "Event reporting" (im EFD) und dem Ereignisprotokol- 
lieren bzw. "Event logging" (LOG) wie die "normalen" Noti- 
fications. Folglich werden die vorstehenden Kriterien 1, 5 
und 6 nicht erfullt. 

20 Die Aufgabe dieser Erfindung besteht darin, ein derartig.es 

-VernE^h^en-^n d— Kom^ n einem 

mehrere Managementebenen aufweisenden Managementnetz vorzu- 
schlagen, das fur unterschiedliche Managementdaten geeignet 
ist und durch das ein Datenabgleich zwischen einem Agent und 
25 zumindest einem Manager weiter verbessert wird. 



Diese Aufgabe wird hinsichtlich des Verfahrens durch die 
Merkmale des Patentanspruchs 1 und hinsichtlich des Kommuni- 
kationssystems durch die Merkmale des Patentanspruchs 10 ge- 
lost. Vorteilhafte Weiterbildungen sind Gegenstand von Un- 
30 teranspruchen. 

Das vorgeschlagene Verfahren ist ein generisches Verfahren 
fur den Ablauf einer Alignment-Prozedur, die alle oben er- 
wahnten Kriterien erfullt. D.h. es ist insbesondere von der 
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Ubertragenen Information bzw. Manager-/Agent-Implementierun- 
gen unabhangig. 

Zudem sind keine zusatzlichen, in den Standards noch nicht 
definierten Notif icationen erforderlich. Dies bedeutet eine 
einfache, standard- konforme Implementierung im Agent und eine 
einfache Korrelation im Manager zwischen Request und Align- 
ment-Notif icationen. 

Das Zwischenschalten der Filtereinheiten zwischen die eigent- 
lxchen Funktionseinheiten von Managern und Agenten entlastet 
dxese zugunsten von deren Routineauf gaben. Eigenstandige 
Fxlterfunktionen fur die Zuordnung von Datenabgleichsdaten zu 
bestimmten Managern sind in Managern und Agenten nicht mehr 
erforderlich. 

Die Filtereinheiten in den Ausgangs- bzw. Ausgabebereichen 
der Agenten anzuordnen entlastet das zwischen Agenten und Ma- 
nagern liegende Kommunikationsnetz bzw. dessen dazwischenlie- 
genden Einrichtungen in besonders vorteilhaf ter Weise. 

Die Verwendung von optionalen Zusatzf eldern, insbesondere dem 
-Feird-"Ad^t^on^tWt'T-CT6W^t-d xe Verwendung der beste- 



henden Standards ohne Neudef initionen . im Idealfall sind le- 
dxgUch programmtechnische Anderungen der Steuersof tware in 
Managern und Agenten erforderlich. 

Nachstehend wird die Erfindung anhand von Ausf uhrungsbeispie- 
len unter Bezugnahme auf die Figuren naher erlautert. Es zei- 
gen 




FIG 1 das Blockschaltbild eines Managementnetzes fur ein 
Mobil-Kommunikationssystem mit Agent-Manager-Bezie- 



FIG 2 



hung zwischen einem Betriebs- und Wartungszentrum und 
einem oder mehreren Netzmanagementzentren, 
das Blockschaltbild des Managementnetzes gemafi Figur 
1 mit Agent-Manager-Beziehung zwischen einem Basis- 



GR 99 P 26 1 



9 

stationssystem und einem Betriebs- und Wartungszen- 

trum zur Durchfuhrung von zumindest zwei Anwendungen 

fur das Basisstationssystem, 
FIG 3 das Blockschaltbild von Agent und Managern zur Be- 

handlung der Ereignisse ftir parallel Oder seriell ab- 

laufende Datenabgleiche, 
FIG 4 den Nachrichtenf lufi zwischen einem Manager und dem 

Agent zur Steuerung der Datenf ilterung am Beispiel 

von Alarmen beim Datenabgleich . 

Das Ausfiihrungsbeispiel beschreibt die Erfindung anhand eines 
beispielhaften TMN-Konzeptes fur das Management eines Mobil- 
Kommunikationssystems, das beispielsweise Netzeinrichtungen 
eines Mobilf unknetzes nach dem UMTS- oder dem GSM-Standard 
aufweist. Das Konzept ist aber nicht auf Mobilfunknetze be- 
schrankt, sondern lafit sich auf Telekommunikationsnetze jeder 
Art anwenden, die ein TMN-Managementnetz nutzen. 

Ein Mobil-Kommunikationssystem ist ein hierarchisch geglie- 
dertes System verschiedener Netzeinrichtungen, bei dem die 
unterste Hierarchiestuf e von den Mobilstationen gebildet 
wird. Diese Mobilstationen kommunizieren liber eine Funk- 

ehii-irt-^s-te-llre— mirt-drire— n^Irstre— Hrerairchreeb ene bxlrien-eterr-Funk- 
stationen, die als Basisstationen bezeichnet werden. Die bei- 
spielsweise Mobilstationen in einem Funkbereich einer Funk- 
zelle versorgenden Basisstationen sind vorzugsweise zur Ab- 
deckung eines groiieren Funkgebiets zusammengef aI3t und mit 
ubergeordneten Netzeinrichtungen, den Basisstationssteuerun- 
gen verbunden. Die Basisstationen und Basisstationssteuerun- 
gen gehoren zu einem Basisstationssystem (Base Station Subsy- 
stem) des Mobil-Kommunikationssystems . Die Basisstations- 
steuerungen kommunizieren Uber definierte Schnittstellen mit 
einer oder mehreren Vermittlungseinrichtungen, den Mobilver- 
mittlungsstellen, uber die u.a. auch der Obergang zu anderen 
Kommunikationsnetzen erfolgt. Die Mobilvermittlungsstellen 
bilden gemeinsam mit einer Mehrzahl von Datenbanken das Ver- 
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mittlungssystem (Switching Subsystem) des Mobil-Kommunikati- 
onssystems . 

Neben den obigen Netzeinrichtungen existieren ein oder meh- 
rere Betriebs- und Wartungszentren (Operation and Maintenance 
Centers), die u.a. zum Konf igurieren und Oberwachen der 
Netzeinrichtungen dient. Oberwachungsmalinahmen und Konfigu- 
rierungsmafinahmen werden hierzu meist vom Betriebs- und War- 
tungszentrum aus f erngesteuert, die ublicherweise im Bereich 
der Mobilvermittlungsstellen angeordnet sind. Ein Betriebs- 
und Wartungszentrum kommuniziert dabei jeweils nit einem Ba- 
sisstationssystem oder Vermittlungssysstem iiber eine defi- 
nierte Schnittstelle . Eine weitere Aufgabe des Betriebs- und 
Wartungssystems ist die Durchftihrung des Konf igurationsmana- 
gements (Configuration Management), das neben dem Fehlermana- 
gement einen von ftinf Managementfunktionsbereichen darstellt 
die die TMN-Prinzipien identif izieren . Das Konf igurationsma- 
nagement definiert eine Reihe von Diensten, die eine Anderung 
der Struktur und damit des Verhaltens eines Telekommunikati- 
onsnetzes durch den Bediener ermoglichen. Diese Dienste be- 
Z1 ehen sich immer auf Instanzen von gemanagten Objekten, die 
insgesamt die netzspezif ische Managementinf ormationsbasis 
-bixdem — — — — 




Em gemanagtes Objekt im Sinne des Konf igurationsmanagements 
ist eine logische Abstraktion einer Ressource im Mobil-Kommu 
nikatxonssystem. Hierbei wird unterschieden zwischen hardwa- 
rebezogenen gemanagten Objekten, die eine herstellerspezif i- 
sche Realisierung einer Funktion beschreiben, und funktions- 
bezogenen gemanagten Objekten, bei denen es sich jeweils urn 
dxe Abstraktion einer herstellerunabhangigen Funktionalitat 
handelt. 




Fur das Management des Mobil-Kommunikationssystems, das im 
folgenden anhand von "Fault Management" erlautert wird, defi- 
nxeren die TMN-Prinzipien mehrere Ebenen ("Levels"), von de- 
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nen im vorliegenden Beispiel drei Ebenen unter Bezugnahme auf 
die Figuren 1 und 2 nachfolgend erlautert werden. 

Die Figuren 1 und 2 zeigen jeweils drei Ebenen A, B und C des 
Managementnetzes, von denen die Managementebene C die Netz- 
5 einrichtungsebene ("Network Element Level") mit mehreren Ba- 
sisstationssystemen BSS11, BSS12 . . . BSS1N sowie BSS21, BSS22 
. . . BSS2M enthalt. Die Managementebene B kennzeichnet die 
Netzeinrichtungsmanagementebene ("Network Element Management 
Level") , in der Betriebs- und Wartungszentren OMC1 und 0MC2 
0 jeweils die herstellerspezif ische Managementf unktionalitat 

fur einzelne Subsysteme, wie im vorliegenden Beispiel das Be- 
triebs- und Wartungszentrum 0MC1 fur die Basisstationssysteme 
BSS11, BSS12 . ..BSS1N und das Betriebs- und Wartungszentrum 
0MC2 for die Basisstationssysteme BSS21, BSS22 . . .BSS2M, be- 
5 reitstellen. Die Managementebene A kennzeichnet die Netzmana- 
gementebene ("Network Management Level"), in der Netzmanage- 
mentzentren NMC1 und NMC2 jeweils eine integrierte, vom Her- 
steller unabhangige Management-Funktionalitat realisieren* 
Dabei konnen mehrere Netzmanagementzentren einen Zugriff zu 
0 derselben Netzeinrichtung der nachstniedrigeren Management- 
ebene B haben, im vorliegenden Beispiel die Netzmanagement- 
— z^en-fe^e^— NMG-3^-und— NMG2— de-r— nra ^ehrs^ho^herrenr-Mana^gemerrtebene— e~ zrtim- 
Betriebs- und Wartungszentrum 0MC1 der nachstniedrigeren Ma- 
nagementebene B. Zwischen den Netzeinrichtungen unterschied- 
licher Managementebenen sind definierte Schnittstellen zur 
Inf ormationsubertragung vorgesehen . 

Der Unterschied in den Darstellungen gemaB den Figuren 1 und 
2 liegt darin, dafi eine Agent -Manage r-Be z i ehung zur Behand- 
lung von Alarmen fur einen oder mehrere Alarmdatenabgleiche 
in Figur 1 zwischen dem Betriebs- und Wartungszentrum 0MC1 
(Agent) und einem Netzmanagementzentrum NMC1 (Manager) oder 
mehreren - physikalisch getrennten - Netzmanagementzentren 
NMC1, NMC2 (Manager) sowie in Figur 2 zwischen dem Basissta- 
tionssystem BSS11 (Agent) und zwei verschiedenen Anwendungen 
0F1 und 0F2 (Manager) in dem Betriebs- und Wartungszentrum 
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OMC1 oder zwischen dem Betriebs- und Wartungszentrum 0MC1 
(Agent) und zwei verschiedenen Anwendungen NF1 und NF2 (Mana- 
ger) in dem Netzmanagementzentrum NMC1 besteht. Urn in den 
Netzmanagementzentren NMC1, NMC2 jederzeit einen Oberblick 
uber die Fehlersituation sicherzustellen, werden vom Be- 
tnebs- und Wartungszentrum 0MC1 die - auf Grund von bei- 
spielsweise innerhalb der betreuten Basisstationssysteme 
BSS11...BSS1N auftretenden Fehlern - gespeicherten Alarmdaten 
ak tl ver Alarme bereitgestellt und parallel zu beiden Managern 
auf Anforderung gesendet . Dies erfolgt vorzugsweise nach ei- 
nem Verbindungsabbruch oder nach einer Initialisierung des 
Agenten oder des Managers . Ebenso konnen mehrere Anf orderun- 
gen auch hintereinander von einem einzelnen Manager, z B de 
Netzmanagementzentrum NMC1 an den Agent, z.B. dem Betriebs- 
und Wartungszentrum 0MC1, gerichtet werden. Figur 1 zeigt die 
Struktur fur gemafi der Erfindung mehrfach ausgesendete Anfor- 
derungen zum Alarmdatenabgleich, die im vorliegenden Beispiel 
parallel zwischen der Managementebene B, in der sich der 
Agent in Form des Betriebs- und Wartungszentrums 0MC1 befin- 
det, und der nachsthoheren Managementebene A, in der die Ma- 
nager von zumindest zwei Netzmanagementzentren NMC1, NMC2 ge- 
bildet werden, ablaufen. 



Urn auch in der Managementebene B, z.B. in dem Betriebs- und 
Wartungszentrum 0MC1 jederzeit einen Oberblick uber die Feh- 

i;" 1 lt " ati ° n Sicherzustel1 ^^ werden vom Basisstationssystem 
BSS11 d le - auf Grund von beispielsweise innerhalb der be- 
treuten Basisstationen und Basisstationssteuerungen auftre- 
tenden Fehlern - gespeicherten Alarmdaten aktiver Alarme be- 
rextgestellt und parallel zu mindestens zwei Managern des Be- 
trrebs- und Wartungszentrums OMC1 in Form der unterschiedli- 
chen Anwendungen 0F1 und 0F2, die beide von ein- und dersel- 
ben physikalischen Einrichtung 0MC1 ausgefuhrt werden, gesen- 
det. Dl es erfolgt ebenfalls vorzugsweise nach einem Verbin- 
dungsabbruch oder nach einer Initialisierung des Agenten oder 
des Managers. Eine serielle Obertragung von mehrfach durch 
Slnen einzelnen Manager, z.B. dem Betriebs- und Wartungszen- 
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trum 0MC1, initiierten Anforderungen an den Agent, z.B. dem 
Basisstationssystem BSS11, ist ebenfalls moglich. Alternativ 
oder zusatzlich kann eine Agent-Manager Beziehung auch zwi- 
schen dem Betriebs- und Wartungszentrum 0MC1 (ein Agent) und 
dem Ne t zmanagement z ent rum NMC1 (ein Manager) zum seriellen 
Austausch von Anforderungen und Alarmdaten oder zum paralle- 
len Austausch von Anforderungen und Alarmdaten fur mindestens 
zwei unterschiedliche Anwendungen NF1 und NF2 (zwei Manager) 
im Net zmanagement zentrum NMC1 existieren. Figur 2 zeigt die 
Struktur fiir gemaJi der Erfindung parallel ablaufende Alarmda- 
tenabgleiche zwischen der Managementebene B, in der sich die 
Manager als Anwendungen OF1 und 0F2 befinden, und der nachst- 
niedrigeren Managementebene C, in der sich der Agent befin- 
det. 

Sobald eine in der Managementebene C ausgefallene interne 
Schnittstelle wieder betriebsbereit ist, wird auf Anforderung 
des Managers/der Manager der Alarmdatenabgleich, auch als 
Realignment-Prozedur oder Realignment-Verf ahren bezeichnet, 
gestartet, wobei gemaft der Erfindung vom Manager der Alarmda- 
tenabgleich parameterabhangig gesteuert wird. Dabei beginnt 
der Alarmdatenabgleich im vorliegenden Beispiel zuerst zwi- 
— sehen— dem— B-as-irs-st-at-ionssystemT — zvB^BSSl~:irr~urrd~d'en^ — 
gen 0F1, 0F2 im Betriebs- und Wartungszentrum 0MC1 parallel 
und setzt sich anschlieBend zwischen dem Betriebs- und War- 
tungszentrum 0MC1 und den ubergeordneten Netzmanagementzen- 
tren NMC1, NMC2 parallel fort. Am Ende dieser Prozeduren ist 
die Fehlersituation sowohl im OMC als auch in den NMC wieder 
aktualisiert . Das Realignment-Verf ahren kann selbstverstand- 
lich auf die Aktualisierung der Alarmdaten zwischen Agent und 
Managern in zwei unmittelbar angrenzenden Managementebenen, 
z.B. Ebene B und Ebene A, beschrankt sein. 

Figur 3 zeigt in schematischer Darstellung den Aufbau von 
Agent AG und Manager MAI, MA2 mit den zur Durchfuhrung simul- 

tan - bei zwei oder mehreren Managern - oder seriell - bei 
nur einem Manager - ablaufender Realignment-Prozeduren erfor- 
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derlichen Einrichtungen. Jeder Manager MAI, MA2 und Agent AG 
verfQgt iiber eine Steuereinrichtung M-CTR bzw. A-CTR, die die 
Nachrichten fUr den Alarmdatenabgleich generieren und auswer- 
ten konnen. Ebenso weisen sie - nicht naher dargestellte - 
Sende/Empfangseinrichtungen fur das Versenden und Empfangen 
der Nachrichten sowie Speichereinrichtungen far das Speichern 
der Alarmdaten und anderer Nutz- und Signalisierungsinforma- 
tionen auf. 



LO 



Dabei fiigen die Steuereinrichtungen M-CTR der Manager MAI, 
MA2 in die jeweilige Anf orderungsnachricht zur Obermittlung 
der Alarmdaten durch den Agent eine zur Zuordnung der Anfor- 
derung zu nachfolgend gesendeten Nachrichten benutzte Korre- 
la tl onsinformation ein, die eindeutig ist, und veranlafit die 
tJbertragung zum Agent. DarUber hinaus fugen die Einrichtungen 
M-CTR der Manager MAI, MA2 zur Steuerung des Alarmdatenab- 
glexchs einen oder mehrere Parameter par in jede Anforde- 
rungsnachricht individuell ein, urn bestimmte, durch verschie- 
dene Parameterwerte gekennzeichnete Alarme gezielt anzufor- 
dern. Dxe jeweilige Anf orderungsnachricht wird mit den Para- 
metern par zum Agent AG gesendet. Erst durch die parametri- 
_ S16rbare Alignment-Funktionalitat gemaJi der Erfindung konnen 

beTspre^weise efinTT>f iori S ierung der Alarme und/oder eine 

ak tl ve Steuerung der Reihenfolge der angeforderten Alarme er- 
zielt werden. 

Die Steuereinrichtung A-CTR des Agent AG empfetngt die ent- 
sprechende Nachricht mit den Parametern par, wertet sie aus 
und startet das Realignment zu den Managern MAI, MA2 durch ' 
Rucksenden der von den Managern spezifisch angeforderten 
Alarme. Dabei wird die von den Managern MAI, MA2 in die An- 
forderungsnachricht eingetragene eindeutige Korrelationsin- 
formation zur Korrelation der Anf orderungen benutzt, und je- 
weils eine Nachricht mit einer weiteren Korrelationsinforma- 
txon zur Zuordnung der nachfolgend vom Agent gesendeten Nach- 
rxchten (alarm notifications) zu dem jeweils gestarteten Rea- 
lignment in die nachsthohere Managementebene gesendet Auch 
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die weitere Korrelationsinformation ist eindeutig. Durch die 
Verwendung der Korrelationsinf ormationen ist eine eindeutige 
Zuordnung simultan oder seriell durchgef Uhrter Realignments 
zu mehreren Managern oder einem einzelnen Manager moglich. 

Besonders die Kombination der Basisf unktionalitat - Verwen- 
dung der Korrelationsinformationen - mit der parametrisierba- 
ren Alignment-Funktionalitat flihrt zu einem besonders effek- 
tiven Verfahren und Kommunikationssystem, das eine optimale 
Nutzung der Ubertragungsressourcen auf der Schnittstelle der 
Agent-Manager-Beziehung sowie ein schnellstmogliches Bereit- 
stellen nur der vom Manager gewunschten Alarmdaten aktiver 
Alarme fur die nachsthohere Managementebene durch den Agent 
bewirkt. Ressourcenausnutzung, Zeitdauer und Flexibilitat 
werden folglich in dem erf indungsgemafi ausgestalteten Kommu- 
nikationssystem gegenuber der Basisfunktionalitat weiter op- 
timiert. Dies gilt zudem nicht nur fur die Alarmverwaltung 
sondern generell fur einen Datenabgleich. 

Wahlweise konnen im Agent AG mehrere, jeweils den Managern 
MAI, MA2 zuordenbare und von ihnen steuerbare Filterf unktio- 
nen EFD1 , EFD2 (Event Forwarding Discriminators) mit Filter- 

-teri-fce-i^iei^^ 

nutzt werden, sodaB die Nachrichten mit den Alarmdaten nur 
bei Erftlllen der Filterkriterien zu den Managern MAI, MA2 ge- 
routet werden. Die Steuereinrichtung M-CTR des Managers ist 
in der Lage, derartige Filterf unktionen im Agent AG einzu- 
richten, zu loschen und die Filterkriterien festzulegen, urn 
je nach seinen individuellen Anf orderungen den Nachrichten- 
flufi steuern zu konnen. Daher kann der Fall auftreten, dafi 
die Filterfunktions-Einstellung von Manager zu Manager unter- 
schiedlich ist, sodaB durch die simultan ablaufenden Realign- 
ment-Prozeduren inhaltlich verschiedene Alarme mit zugehori- 
gen Alarmdaten behandelt werden. 

Figur 4 zeigt den Nachrichtenf lufl zwischen einem Agent AG - 
im dargestellten Beispiel gemaB der Figur 1 dem Betriebs- und 
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Wartungszentrum 0MC1 oder im dargestellten Beispiel der Figur 
2 dem Basisstationssystem BSS11 - und dem Manager MAI, MA2, 

MAn - im Beispiel gemafi der Figur 1 den unterschiedlichen 
Netzmanagementzentren NMC1, NMC2 oder im Beispiel der Figur 2 
den verschiedenen Applikationen 0F1, 0F2 . 

Der Nachrichtenflufi erfolgt vorzugsweise unter Verwendung 
standardisierter M-EVENT-REPORT Nachrichten, die als Folge 
exner zu Anfang initiierten M-ACTION-Request "Anf orderung" 
gesendet werden. Diese sind generische CMISE-standardisierte 
(Common Management Information Service Element) Dienste die 
gemafi ITU-T X.710 definiert sind. Die ITU-T X.733 definiert 
den inhalt einer standardisierten Alarmubertragung (alarm re 
port), die gemafi den M-EVENT-REPORT Services durchgef tihrt 
wxrd. Korrelationsinformationen werden in die Nachrichten 
bzw. in bestimmte Nachrichtenf elder eingetragen. Das Beispiel 
xn Fxgur 4 zeigt den Nachrichtenf lufi nur anhand einzelner 
Nachrichten, wobei diese parallel zwischen dem Agent AG und 
den Managern MAI, MA2 oder seriell zwischen dem Agent AG und 
dem einzelnen Manager MAI ubertragen werden k6nnen, wie dies 
bxs hxer aus z.B. der DE 198 01 785 bekannt ist. 




-^^eg^d^e^derte^m^-rer- dargestellten A usl: u hrungsbeispiel 
z.B. exnes Alarm-Alignment-Beispiels insbesondere die folgen- 
den, im Standard ITU-T X.721 spezif izierten Merkmale verwen- 
det . 

• Jede fur ein Alignment-Verf ahren in Frage kommende stan- 
dardisierte Notification (alarm notification, state change 
notxfxcation, attribute value change notification, object 
creatxon notification, object deletion notification) ent- 
halt als optionalen Parameter (Attribut) den Zusatztext 
(Additional text) . 

Die Definition des Parameters "Additional text" (vom Typ 
GraphicString, d.h. Zeichenkette) enthalt die Klausel: 
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"Obereinstimmungsbegrif fe fur Gleichheit, Unterketten" 
("MATCHES FOR EQUALITY, SUBSTRINGS") . 

Gemafi Standard ITU-T X.722 kann dieses Attribut auf das Vor- 
handensein einer bestimmten Sub-Zeichenkette (SUBSTRING) ge- 
5 testet werden. Das Testergebnis kann insbesondere in EFD- 
oder LOG-Instanzen auch als Filterkriterium fur diejenigen 
Notif icationen verwendet werden, die dieses Attribut enthal- 
ten. 

Der Ablauf der beispielhaf ten Alignment-Prozedur wird nun an- 
0 hand der verwendeten Befehle erlautert. 

Im normalen Betrieb enthalt die Vorgabe- bzw. Default-Fil- 
tereinstellung jeder EFD-Instanz im Agent die hier als Klar- 
text beschriebene Klausel: 

<Jede Notification mit der Zeichenkette "ALIGNMENT" im 
5 Additional text-Feld wird ausgef iltert> . 

Durch die Verwendung dieser Klausel wird insbesondere durch 
die EFDs verhindert, dafi ein Manager diejenigen Notificatio- 

nen-e-rh-ait— d±e— a±s— Fcrt^e— e-in-er— durc-h einen anderen Manager 

initiierten Alignment-Prozedur gesendet werden. 

Jedesmal wenn ein Manager (z.B. Manager 2) einen Alignment- 
Vorgang startet, ersetzt er die Def ault-Filtereinstellung 
seiner EFD-Instanz im Agent durch eine Alignment-Filterein- 
stellung in Art der folgenden Klausel, die hier wieder als 
Klartext beschrieben ist: 

<Jede Notification mit den SUBSTRINGS " ( a a a a - AL I GNMENT " 
Oder " (aaaa-ENDALIGNMENT" im "Additional text"-Feld 
wird nicht ausgef iltert . >, 
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wobei aaaa eine Nummer ist, die den aktuellen Manager eindeu- 
tig kennzeichnet. Diese Nummer kann z.B. vom Agent bei jedem 
Verbindungsaufbau zum aktuellen Manager vergeben werden. 

Jedesmal wenn die Kommunikation zwischen einem Manager (z B 
Manager 2) und Agent wieder hergestellt wird, z.B. nach einer 
Unterbrechung der Verbindung, sendet dieser Manager eine 
CMISE-standardisierte M-ACTION-Anweisung mit folgenden Para- 
metern an den Agent: 



Aktionstyp: 
(Action type: 

Aktionsinformation: 
(Action information) 



"Datensynchronisierung anfordern" 
"requestDataSynchronisation") . 

"Manager-Handling" (managerHandle) , 
z.B. der zuvor definierte Wert aaaa). 
Diese eindeutige Nummer wird vom Agent 
als Antwort auf den aktuellen Manager- 
Request zur Identifizierung aller 
nachfolgend gesendeten Notif icationen 
verwendet . 




^Alignment-Handling" (alignment- 



Handle), z.B. mit einem Wert abc. Die 
ser Parameter identif iziert fur den 
Manager 2 den aktuellen Alignment-Vor 
gang eindeutig. Wie das oben erwahnte 
Kriterium 9 spezif iziert, mufi der Ma- 
nager die empfangenen, alignment-bezo- 
genen Notif icationen dem richtigen 
Alignment-Vorgang zuordnen, auch wenn 
mehrere eigene Alignment-Prozeduren 
zur gleichen Zeit laufen sollten. 

"Datentyp" (dataType) . 
Dieser Parameter spezifiziert die Art 
der Daten, die zwischen Agent und Ma- 
nager synchronisiert werden sollen, 
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also z.B. Alarme, Zustande oder Konfi- 
gurat ionsanderungen . 

* "bezogene Einheiten" (relatedEntities) 
Dieser Parameter gibt an, von welchen 
Netzeinheiten die angef orderten Daten 
stammen sollen (z.B, von einer be- 
stimmten Netzregion) . 

* "bezogenes Zeitintervall" 
(relatedTimelnterval) . 
Dieser Parameter spezifiziert den 
Zeitrahmen, in dem die vom Agent zu 
sendenden Notif icationen entstanden 
sind, z.B. alle Alarme zwischen 18:00 
und 22:00 Uhr. 

* "spezifische Parameter" (specif icPara- 
meters) . 

Abhangig vom oben-def inierten Parame- 
ter "Datentyp" (dataType) werden in 
diesem Feld spezifische Parameter de- 

fim-i-e-r Irr^z-rB-; — f tir— A±arme , nur d ire j~e~n~i~=~~ 

gen mit einem bestimmten perceivedSe- 
verity-Wert) . . 

Nach Bestatigung der Anforderung durch eine "M-ACTION Re- 
sponse" sendet der Agent hintereinander alle betreffenden No- 
tificationen an alle vorhandenen EFD-Instanzen (gemafl ITU-T 
Standard X.734) . Mit Ausnahme der letzten Notification ent- 
halt jede fur den Datenabgleich bzw. Alignment gesendete No- 
tification am Anfang des Zusatztext-Feldes "Additional text" 
die Zeichenkette " (aaaa-ALIGNMENT-abc) ", wobei aaaa und abc 
die vorher erlauterte Bedeutung haben. 
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10 



Die letzte vom Agent gesendete Notification fur diesen Align- 
ment-Vorgang enthalt am Anfang des Zusatztext-Feldes "Addi- 
tional text" die Zeichenkette " (aaaa-ENDALIGNMENT-abc) " . 

Die gesonderte Filtereinstellung der EFD-Instanz des Managers 
2 stellt sicher, dafi die vom Agent far den Alignment gesende- 
ten Notificationen nur diesen einen Diskriminator passieren 
konnen. Auch wenn ein anderer Manager (Manager 1) zur glei- 
chen Zeit eine Alignment-Prozedur mit z.B. dem eindeutigen 
"alignmentHandle" = "bbbb" startet, erhalt Manager 2 nur 
"seine" Notificationen mit der Kennung aaaa. 

Fig. 4 zeigt einen beispielhaf ten Nachrichten-Austausch zwi- 
schen einem Manager a und einem Agent fur eine Alarm-Align- 
ment-Prozedur, wobei die Parameter "managerHandle" z.B. den 
Wert 78 und alignmentHandle z.B. den Wert 123 haben. 

15 Wahrend der Alignment-Prozedur konnen neu entstandene Notifi- 
cationen, die nicht als Folge einer gerade laufenden Align- 
ment-Prozedur gesendet werden und deshalb keine Sonderstrings 
enthalten, grundsatzlich alle EFD-Instanzen passieren (z B 
Notification 3 in Fig. 4), d.h. alle ubergeordneten Managers 
-2-0 errexchren- — _ 

Der Manager a ist auch in der Lage das Ende seiner Alignment 
Prozedur zu erkennen, hier der Notification n mit der eindeu 
tigen Kennung "(aaaa-ENDALIGNMENT-abc)". 

Am Ende der Alignment-Prozedur, d.h. nach dem Emp fang der No- 
tification mit dem SUBSTRING "(aaaa-ENDALIGNMENT-abc)", setzt 
der Manager a die Def ault-Filtereinstellung zuriick. 

Wenn zum Zeitpunkt des Manager-Request kein Alignment erfor- 
derlxch ist, weil z.B. keine aktiven Alarme vorhanden sind, 
erhalt der Manager a in der "M-ACTION-Response" (Parameter 
Action reply) einen entsprechenden Hinweis. 




GR 99 P 2 



21 

Alternativ konnen die EFDs auch Bestandteil der entsprechen- 
den Manager oder einer zwischen Manager und Agent geschalte- 
ten Einheit sein. Der Manager selber soil dadurch entlastet 
werden, dafi die nicht fiir ihn bestimmten Inf ormationen vor 
der Ankunft bei ihm durch den ihm zugeordneten EFD herausge- 
filtert werden. 

Die gleiche Vorgehensweise kann auch fur LOG-Diskriminatoren 
verwendet werden oder bei sonstigen vergleichbaren Einheiten 
mit Filterfahigkeiten ausgebildet oder Bestandteil von diesen 
sein. 
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Patentanspruche 



1. Verfahren zum Datenabgleich durch ein zumindest zwei Mana- 

gementebenen (A, B, C) aufweisendes Managements z, wobei fur 

exnen Datenabgleich zwischen zumindest einem Agent (AG) einer 

Managementebene ( B/ C) und zumindest einem Manager (MAI, MA2) 

611161 nachsth ^eren Managementebene (A, B) Daten ubertragen 
werden, bei dem 

- von dem Manager (MAI, MA2) jeweils eine Oder mehrere Anfor- 
10 derungsnachrichten zum Obermitteln der Daten an den Agent 
(AG) gesendet werden, 

-wobei der Manager (MAI, MA2) Korrelationsinformationen fur 
erne Zuordnung der jeweiligen Anforderung zu den vo. Agent 
(AG) nachfolgend geaendeten Nachrichten ubermittelt, 
15 dadurch g e k e n n z e i c h n e t , 

AaL Fllt , a T rlChtUn9en <EFD) ™ det »"den, Daten von 

und T U " abh ^ ™- anrordernden Manager empfangen 

und dre empfangenen Daten abhangrg von Korrelationstnforma- 
tronen nur zum anrordernden Manager hindurchlassen, wobei die 
•0 Frlterernrrchtungen von den eigentiichen Funktionen von Agen- 
ten und Managern generisch und/oder unabhangig sind. 
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— ^T-Vexfalrren naclTAnsprucirTT-beTr-deS " 

die bei- Datenabgleich abzugleichenden Daten Alarmdaten ins- 
besondere aktiver Alarme, Zustandsanderungen (state changes, 
Oder Konfrgurationsanderungen sind. 

3. Verfahren nach Anspruch 1 oder 2, bei dem 

dre Korrelationsinformationen vom Manager vor dem ubermittein 

,Lh\ ,° naleS ZUSatzfeld ' insbesondere Zusatztextf eld 
(Addrtronal text) eingesetzt werden. 

4. Verfahren nach einem vorhergehenden Anspruch, bei dem 
als Frlteretnrichtungen (EFD) Bestandteile der entsprechenden 
Manager (MAl, MA2, MAn, , der Agenten (AG) oder von zwischen 
Manager und Agent geschalteten Einheiten verwendet werden 
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5. Verfahren nach einem vorhergehenden Anspruch, bei dem 
als Filtereinrichtungen (EFD) Ereignisweiterleitungs-Diskri- 
minatoren, LOG-Diskriminatoren oder sonstige Einheiten mit 
Filter fahigkeiten verwendet werden. 

6. Verfahren nach einem vorhergehenden Anspruch, bei dem 
standardmaliig die Def ault-Filtereinstellung eines Zusatzfel- 
des (Additional text) jeder Filtereinrichtung (EFD) zum Her- 
ausfiltern aller Datenabgleichs-Daten eingestellt wird. 

7. Verfahren nach Anspruch 6, bei dem 

die Filtereinstellung des Zusatzfeldes (Additional text) der 
Filtereinrichtung (EFD) des einen Datenabgleich anfordernden 
Managers (MA 2) nach dem Datenabgleich auf die Def ault-Fil- 
tereinstellung zuruckgestellt wird. 

8. Verfahren nach einem vorhergehenden Anspruch, bei dem 
die Filtereinstellung eines Zusatzfeldes (Additional text) 
der Filtereinrichtung (EFD) des einen Datenabgleich anfor- 
dernden Managers (MA 2) zum Herausf iltern aller fremden Da- 
tenabgleichs-Daten eingestellt wird. 

—9-v— Verfahren— n-aeh— einem- vo-rhergehenden— Anspruch^ — bei^dem 

alle Datenabgleichs-Daten sendenden Agenten (AG) die Daten 
mit der Korrelationsinf ormation im Zusatzfeld an die Fil- 
tereinrichtungen (EFD) von alien Managern ubermitteln. 

10. Kommunikationssystem, insbesondere Funk-Kommunikationssy- 
stem mit einem zumindest zwei Managementebenen (A, B, C) auf- 
weisenden Managementnetz, mit 

- Einrichtungen, die als Manager (MAI, MA2 , MAn) und/oder als 
Agent (AG) einsetzbar sind, 

- Einrichtungen zum Datenabgleich nach insbesondere einem 
Verfahren nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 

daft die Einrichtungen zum Datenabgleich eigenstandige Fil- 
tereinrichtungen (EFDs) aufweisen, die als eigenstandige 
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Funktionseinheiten zwischen den eigentlichen Funktionseinhei- 
ten von Managern und Agenten angeordnet sind. 

11. Kommunikationssystem nach Anspruch 10, bei dem 
im Manager (MAI, MA2) Einrichtungen zum Einstellen von Fil- 
ter bzw. Korrelationsinformationen in zugeordneten Fil- 
tereinrichtungen (EFD) bereitgestellt sind. 

12. Kommunikationssystem nach Anspruch 10 oder 11, bei dem 
un Agent (AG) Einrichtungen zum Einsetzen von den Filter- 
bzw. Korrelationsinformationen in Zusatzfelder von Datenin- 
formationen, die uber zumindest eine Filtereinrichtung (EFD) 
zu einem Manager zu Ubertragen sind, bereitgestellt sind. 

13. Kommunikationssystem nach einem der Anspruche 10 - 12 
bex dem die Filtereinrichtungen (EFDs) Bestandteile der ent- 
sprechenden Manager (MAI, MA2, MAn) , Agenten (AG) oder von 
separat zwischen Manager und Agent geschalteten Einheiten 
sind. 

14. Kommunikationssystem nach einem der AnsprUche 10 - 13 
bex dem die Filtereinrichtungen Ereignisweiterleitungs-Dis- 

ten mat Filterf ahigkeiten sind. 
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Zusammenf as sung 

Generisches Alignment-Verf ahren in einer Multi-Manager-Umge- 
bung 

Die Erfindung betrifft ein Verfahren und ein Kommunikations- 
system zum Datenabgleich durch ein zumindest zwei Manage- 
mentebenen (A, B, C) aufweisendes Managementnetz, wobei fur 
einen Datenabgleich zwischen zumindest einem Agent (AG) einer 
Managementebene (B, C) und zumindest einem Manager (MAI, MA2) 
einer nachsthoheren Managementebene (A, B) Daten von sponta- 
nen Ereignissen (aktive Alarme, Zustands- oder Konfigurati- 
onsanderungen) ubertragen werden. Dabei werden von dem Mana- 
ger (MAI, MA2) jeweils eine oder mehrere Anforderungsnach- 
richten zum Obermitteln der Alarmdaten an den Agent (AG) ge- 
sendet, wobei der Manager (MAI, MA2) Korrelationsinf ormatio- 
nen fUr eine Zuordnung der jeweiligen Anforderung zu den vom 
Agent (AG) nachfolgend gesendeten Nachrichten ubermittelt. 

Zur Entlastung sowohl der Manager als auch der Agenten werden 
die angef orderten Daten vom. Agenten aus zusammen mit der in 
ein optionales Zusatzfeld (Additional text) eingesetzten Kon- 



nagern und den bzw. den Agent (en) eingesetzte Filtereinrich- 
tungen (EFD) lassen nur die Daten hindurch, die zu den diesen 
zugeordneten Managern zu ubertragen sind. 
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Manager x Agent 
M-ACTION Request: requestDataSynchronisatior^ 

(managerHandle = 78, alignment Handle 123, dataType = alarms, 
related entities = relatedTimelntervall = .., specificParameters = ..) 

M-ACTION Response: requestDataSynchronisation 

M — 

(alignment Handle 123) 

4 M- EVENT-REPORT: alarm Notification 
-AdditionalText^(78^AyGNME^ 

4 M-EVENT-REPORT: alarm Notification 
AdditionalText: °(78- ALIGNMENT-123) ...other information. 

< M-EVENT-REPORT: alarm Notification 
AdditionalText: "...other information..." 



M-EVENT-REPORT: alarm Notification 
AdditionalText: "(78- EN D ALI GN M ENT- 1 23) ...other information. 

, M-EVENT-REPORT: alarm Notification 



AdditionalText: "...other information. 
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